@dessalines - we have come up with 2 different authentication approaches in these latest PRs

happy to go with whichever you think is best :)

Some of the problems our PRs solve overlap and some don't. Some notes on your PR:

• I'm surprised you were able to make requests from the server functions to the API without setting up proxying as as done in this PR. Attempts to do that failed for me without setting up the actix server to handle requests to the /api/* route differently.
• Managing cookies on the client side seems like it has more errors that need to be handled than I would expect. I wonder if there's an easier way to to this.
• When running your changes locally, can you hit the API when using localhost:1237 as the host, e.g. localhost:1237/api/v3/post/list? Other lemmy UIs are going to need to have requests to the API go through for them to work.

thanks for looking at the PR! i hope we can use the best bit from both our PRs.

* I'm surprised you were able to make requests from the server functions to the API without setting up proxying as as done in this PR. Attempts to do that failed for me without setting up the actix server to handle requests to the /api/* route differently.

i had no issues at all making authentication calls from server functions or content API calls to Voyager in SSR mode. Voyager also sets CORS headers to allow the same API calls direct from the browser. i'm also seeing personalized data when i set the Authorization headers, so that all seems to be working great. maybe some network peculiarities are preventing you from doing the same, or calling your own dev lemmy API.

* Managing cookies on the client side seems like it has more errors that need to be handled than I would expect. I wonder if there's an easier way to to this.

this is the first iteration of my browser/server cookie handling code. open to any suggestions to improve any code in the PR.

Rust wonderfully makes us aware of all the possibilities that emerge from our code. i have tried to allow errors to gracefully be passed up the call stack without masking the original error. i hope this means any errors can be handled at an appropriate error boundary and there will be enough detail in the error to aid debugging and useful error handling. i see there is an Issue open to define errors and handling strategy in the app. i should add any ideas in there i guess.

* When running your changes locally, can you hit the API when using localhost:1237 as the host, e.g. localhost:1237/api/v3/post/list? Other lemmy UIs are going to need to have requests to the API go through for them to work.

i have not set up my own instance as yet but i will spin up either a containerized (if one exists with the correct lemmy API) or native instance and try it out.

As a heads up, I'm likely going to close this PR without merging in the future after #19 gets merged. I have 3 reasons for this:

1. I think managing the cookies on the client side will be unnecessary, as cookies are already always sent with requests from the browser.
2. My PR should avoid creating more than one client on the server side. While my PR uses awc as the HTTP client library, the reqwest docs also suggest creating only one client and reusing it. If I understand correctly, the api wrapper currently creates a new client every time a request is made, which is something that should be avoided if possible.
3. I am going to experiment with a different approach to letting the browser side know that a user is logged in, as well as managing the state of the site more generally.

I will will wait a few days to see if @dessalines has any input on either of our PRs. If we hear nothing back from him after a few more days, I will merge my PR and get started on my attempt at session handling.

@SleeplessOne1917 don't close this one, @jim-taylor-business fully got authentication working here, as well as a lot of other additions like translations and a fuller navbar.

Work with them to fix some of the conflicts, and figure out the optimal way to do authentication.

There's a ./format.sh script in the top level dir, I'll run it for ya here.